1. FIELD OF THE INVENTION
This invention relates to the field of computer network communication, and, more specifically, to the transportation of scenegraph information across a network.
Sun, Sun Microsystems, the Sun logo, Java, Java 3D and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
2. BACKGROUND ART
In present computer systems, it is possible to create a visual representation of a scene in which the scene description contains information regarding three physical dimensions. The use of such xe2x80x9c3Dxe2x80x9d scenes is becoming increasingly important as a way to create xe2x80x9cuser friendlyxe2x80x9d interfaces to complex software applications, for example. In current practice, 3D scene descriptions are frequently organized in the form of directed acyclic graphs called scenegraphs. A scenegraph is a tree structure comprising a multiplicity of nodes interconnected in a hierarchical manner. This hierarchical structure provides a well-organized framework for describing a 3D scene, and one in which functionality may be easily augmented through the addition of one or more nodes to an existing scenegraph.
A consideration in the use of scenegraphs is that computer systems are frequently operated in conjunction with a network. It is therefore desirable to transfer scenegraph information across the network in a platform and application independent manner. There presently exist schemes that attempt to accomplish such a transfer of scenegraph information. One such scheme involves representing scenegraph information in the xe2x80x9cVirtual Reality Modeling Languagexe2x80x9d (VRML), and transmitting the VRML data in an editable text file across a network using standard network protocols, such as http and ftp. These techniques use a textually represented (e.g., ASCII) sequence of symbols as a least common denominator for reliably transferring scenegraph descriptions. Sometimes the textual sequences are compressed into a binary format for transmission purposes.
A problem with using VRML and other passive, fixed-format mechanisms for transporting scenegraph information is that the receiving client application must include a mechanism for parsing and interpreting the received scenegraph information to construct the 3D scene. There is little flexibility for altering the representation of the scenegraph information for transmission, even if more efficient representations are developed, because the client""s implementation of the parser/interpreter is fixed. A new format would require reprogramming of the client application to add the necessary parsing and interpreting support.
The scenegraph programming model provides a simple and flexible mechanism for representing and rendering scenes. Individual graphics elements are constructed as separate node objects and connected together in a treelike structure. Those node objects are then manipulated using their predefined accessor, mutator and node-linking methods.
For reference, an object is a programming unit that groups together a data structure (one or more instance variables) and the operations (methods) that can use or affect that data. Thus, an object consists of data and one or more operations or procedures that can be performed on that data. An object can be instructed to perform one of its methods when it receives a xe2x80x9cmessage.xe2x80x9d A message is a command or instruction sent to the object to execute a certain method. A message consists of a method selection (e.g., method name) and zero or more arguments. A message tells the receiving object what operations to perform.
Any given object is an xe2x80x9cinstancexe2x80x9d of a particular class. A class provides a definition for an object which typically includes both fields (e.g., variables) and methods. (The term xe2x80x9cobjectxe2x80x9d by itself is often used interchangeably to refer to a particular class or a particular instance.) An instance of a class includes the variables and methods defined for that class. Multiple instances can be created from the same class.
The scenegraph contains a complete description of the entire scene, or virtual universe. This includes the geometric data, the attribute information, and the viewing information needed to render the scene from a particular point of view. In the case of a 3D scene, the scenegraph hierarchy promotes a spatial grouping of geometric objects found at the leaves (i.e., end nodes) of the scenegraph. Internal nodes act to group their children together. A group node may also define a spatial bound that contains all the geometry defined by its descendants. Spatial grouping allows for efficient implementation of operations such as proximity detection, collision detection, view frustrum culling and occlusion culling.
Node objects of a scenegraph may be separated into xe2x80x9cgroup nodexe2x80x9d objects and xe2x80x9cleaf nodexe2x80x9d objects. Group node objects group together one or more child nodes, and can be used to define behavior or relationships common to those child nodes. Leaf node objects contain the actual definitions of shapes (geometry), lights, fog, sound, etc. A leaf node has no children and only one parent. The state of a leaf node includes any state in a direct path between the leaf node and the source or xe2x80x9crootxe2x80x9d node of the scenegraph. When a scene is rendered, the renderer incorporates all state changes made in a direct path from the root node of the scenegraph to a leaf node object in the drawing of that leaf node object.
FIG. 1 illustrates a general scenegraph structure used to represent a 3D scene in accordance, for example, with scenegraph policies as described in the Java 3D(trademark) API Specification available from Sun Microsystems, Inc. The scenegraph of FIG. 1 comprises a single root node, referred to as virtual universe (VU) 100, one or more locale nodes (LO) 101, one or more branch group nodes (BG) 102, one or more group nodes (GN) 103, and one or more leaf nodes (LN) 104.
Virtual universe 100 represents the center of the scene, with all child nodes being positioned relative to it. One or more high-resolution locale nodes 101 are coupled to virtual universe 100. Each such locale node 101 specifies a relative offset position with respect to virtual universe 100. This relative offset is represented in a high-resolution format to accommodate distance relationships comparable to the smallest and largest conceived distances in the real world. Each locale node 101 may be used to attach one or more branch group nodes 102, whose rendering positions are interpreted relative to the given locale node 101.
Branch group nodes 102 generally act as a root node of a subgraph associated with the given parent locale node 101. When a branch group node 102 is attached to a locale node 101, and hence to a virtual universe 100, the branch group node and its descendants are considered xe2x80x9clivexe2x80x9d (i.e., ready to render) with respect to the scene. One or more general group nodes 103 may be attached as child nodes to each branch group node 102. Each group node 103 may support zero or more child nodes in the form of further group nodes 103 or leaf nodes 104.
An example of an implementation of a group node 103 is as a transform node that contains a transform matrix used to scale, rotate, and position its descendants. Other group nodes implemented as xe2x80x9cbehaviorxe2x80x9d nodes may be used to embody algorithms for modifying the transform matrices of specified transform objects. Certain leaf node objects may also have references to component objects (not shown) which specify specific attributes of the given leaf node object (e.g., a shape leaf node may have as associated component objects a geometry component object, specifying a geometric shape of the shape leaf node, and an appearance component object, specifying the appearance of the shape in terms of color, texture, etc.). One leaf node is typically used to represent the viewing platform for rendering purposes, with associated component objects for specifying attributes of the rendering viewpoint, as well as the canvas or screen on which the rendered output is to be displayed.
In the construction of a scenegraph, a child node object is attached to a parent group node object by calling the xe2x80x9caddChildxe2x80x9d method of the parent node object and specifying the child node object in the input field. A reference to the child node object is then stored in the parent node object, enabling general scenegraph mechanisms, such as traversal methods, to be implemented between the parent and child node objects. Other specific mechanisms for linking child nodes may be implemented for specific node object types. Also, constraints may be placed on what types of node objects may be linked as children to other specific node types to enforce particular nodal relationships of scenegraph implementations.
As previously stated, the representation of scenegraphs prior to their construction as linked node objects is typically in the form of textual symbols. One format for providing scenegraph information is VRML, although other formats associated with certain computer aided design applications are also used. The textual symbols are stored in an editable text file, or compressed into a binary form (e.g., in accordance with an MPEG file compression format), and transmitted to a client rendering application upon request. An example of a VRML-based scenegraph transmission scheme is illustrated in FIG. 2.
In FIG. 2, a server 200 is coupled to a client application 201 via a network communication mechanism 202, such as an internet or internet. Server 200 comprises one or more VRML files 204 containing scenegraph information associated with one or more scenes. When client application 201 wants to render a given scene, client application 201 issues a request 203 to server 200, specifying the desired scenegraph (e.g., by URL). Server 200 then transmits the desired scenegraph information (e.g., using http, ftp, or other file transfer protocols) in a text or binary transfer 205 over communication mechanism 202.
At client application 201, a parser/interpreter 206 is required to receive the transmitted VRML information, parse out the textual symbols describing the scenegraph and interpret the symbols to identify the components and interconnections of the scenegraph. Parser/interpreter 206 must then construct the scenegraph scene by performing the steps of instantiating the appropriate node classes to obtain appropriate node objects, linking the node objects as defined by the scenegraph information, and populating the node objects with any initial values specified in the scenegraph information of VRML file 204. The result of the scenegraph construction is scenegraph application 207, which may be used by client application 201 to render the desired scene.
The above transmission scheme is inefficient because client application 201 is required to include support in the form of a parser/interpreter 206 for every file format under which scenegraph information transmission is anticipated. Support for multiple transmission formats results in undesired bloating of the client application 201. Further, client application 201 must be reprogrammed and compiled to add the functionality of each new parser/interpreter 206. It would be desirable to have a scenegraph transmission scheme that provides flexible support for multiple scenegraph information formats without the need for altering the client platform.
A method and apparatus for transport of scenegraph information across a network are described. A server obtains a build object comprising a data structure and one or more methods configured to build a scenegraph from scenegraph information stored in the data structure. A spawning process on the server initializes the build object by writing scenegraph information of a desired scenegraph into the data structure of the build object. The initialized build object is then transmitted to the client and loaded. One or more methods of the build object are invoked at the client to generate the desired scenegraph from the information contained in the build object""s data structure. The scenegraph building mechanisms are transparent to the client. Thus, the format by which the scenegraph is represented in the data structure of the build object and/or the build methods of the build object may vary among servers, or may vary for the same server over time, without requiring the client to be reprogrammed.
In one embodiment, transmission of the build object is accomplished by serializing the object and storing the serialized object in a distributed repository. The client either polls the repository mechanism or is notified that the serialized object has been stored therein. The client then reads the serialized object from the distributed repository and deserializes the object for loading into the client""s object-oriented runtime environment.